As used herein, the term “soft SMI” means a system management interrupt (SMI) that occurs in response to a software-generated event, and is not generated by hardware alone. The term “service requestor” is a driver or other executable code that invokes an SMI to request that an SMI handler perform a certain task. The term “SMI handler” is a software routine that was specifically identified by the service requestor to perform the task. The term “SMI infrastructure” is a body of code that handles all SMIs, identifies the causes of the SMIs, and routes the execution path to the correct SMI handler for a given SMI cause. The term “SMM” refers to system management mode, which is a mode that a central processing unit (CPU) enters in response to an SMI event. The term “task” is a function or operation that is performed by the SMI handler for the service requestor.
The term “context” is a body of data that maintains the state of a task while it is executing, including a succession of return addresses, parameters passed between subroutines, and temporary intermediate variables. The context of a task in an SMI handler is normally stored on a stack. The term “task context stack” is a temporary stack created for storage of the context of the specific SMI handler. This stack persists between SMIs until the task is complete. The term “SMI duration” is the delay from the invocation of an SMI by the service requestor until the return of control back to the service requestor, and is a measure of the total time spent with the CPU in SMM for one SMI event. The term “SMI duration limit” is the maximum desired or permissible SMI duration.
Time spent in system management interrupt (SMI) mode is time spent away from the operating system (OS). While servicing an SMI, the OS is unable to task switch or service hardware interrupts. There is a practical limit as to how long an SMI can last before abnormal OS behavior is observed. A value of several hundred microseconds is often used as a maximum desirable SMI duration limit.
SMIs occur for two reasons. These are to service hardware events such as are used for power management or other system management events, and software events such as security operations or other runtime basic input/output system (BIOS) services. When the SMI occurs because a service was requested by software, this is called a software SMI or soft SMI. Many tasks that must be executed as a soft SMI take longer than the SMI duration limit. Particularly, complex cryptographic operations, for example, may take much longer.
One prior art solution is to break down these complex tasks into smaller subtasks and repeatedly invoke soft SMIs until the whole task is completed. This approach, however, calls for the re engineering of the task in such a way that it can be broken down into smaller tasks. It would be desirable to have a method that overcomes the problems and limitations of such prior art solutions.